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Abstract 


This  report  documents  ideas  and  recommendations  for  improving  the  overall  acquisition  process 
and  presents  the  actions  taken  by  project  managers  in  several  programs  to  develop,  staff,  and  ob¬ 
tain  approval  for  their  systems.  This  report  contains  information  on  the  decision  briefings  and  les¬ 
sons  learned,  and  describes  issues  encountered  and  the  recommendations  regarding  the  actual 
processes  that  were  followed.  Finally,  this  report  includes  checklists  of  required  actions  that  will 
assist  new  and  existing  Program  Management  Offices  (PMOs)  as  they  prepare  for  milestone  re¬ 
views. 
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1  Introduction 


1 .1  Context 

Although  the  systems  acquisition  life-cycle  process  is  well  known  and  accepted  by  the  systems 
acquisition  community,  it  does  not  necessarily  support  time-urgent  requirements  that  result  in  a 
new  start.*  Statute  requirements  drive  much  of  the  process  and  are  not  a  prescription  to  circum¬ 
venting  that  process.  Included  in  this  document  are  ideas  and  recommendations  that  can  make  or 
could  have  made  the  overall  acquisition  process  easier,  quicker,  and  less  repetitive. 

Based  on  the  experience  of  the  product  managers  (PMs),  this  report  prescribes  insights  and  les¬ 
sons  learned  from  every  major  facet  of  a  normal  acquisition  program.  The  experiences  outlined  in 
this  report  may  not  reflect  those  of  other  PMs,  and  their  programs  may  not  pose  the  same  chal¬ 
lenges  and  requirements  as  others.  However,  the  intent  is  to  provide  information  in  an  effort  to  (1) 
prevent  someone  from  repeating  past  mistakes  and  (2)  set  the  conditions  to  capitalize  on  past  suc¬ 
cesses. 

This  report  describes  the  actions  taken  by  the  project  and  product  managers  to  develop,  staff,  and 
obtain  approval  for  their  systems.  The  report  contains  information  on  the  decision  briefings  and 
lessons  learned,  and  also  describes  issues  encountered  and  the  recommendations  regarding  the 
actual  processes  the  PMs  followed.  Finally,  the  report  includes  checklists  of  required  actions  (gar¬ 
nered  from  lessons  learned  reports  and  recorded  interviews)  that  will  be  of  assistance  during  mi¬ 
lestone  review  preparation. 

1.2  Background 

At  the  direction  of  the  Program  Executive  Office  (PEO)  Aviation,  this  report  provides  an  account¬ 
ing  of  the  lessons  learned  by  Longbow  Apache  Block  III,  Armed  Reconnaissance  Helicopter,  Ra¬ 
ven,  UH-60M  Modernization  Product  Office,  and  Warrior.  These  lessons  learned  were  accom¬ 
plished  during  the  milestone  review  process,  which  took  place  between  January  2005  and  April 
2007  and  represent  one  ACAT  I  and  two  ACAT  II  unmanned  aerial  systems. 

1.3  Purpose 

This  report  is  intended  to  provide  usable  and  actionable  information  for  new-start  and  existing 
Program  Management  Offices  (PMOs)  that  are  working  through  the  milestone  review  process. 
The  intent  of  this  report  is  not  to  provide  a  — ho\^o”  in  lieu  of  the  published  acquisition  process; 
rather,  the  report  provides  insights  and  lessons  learned  to  benefit  those  who  are  working  through 
the  acquisition  process. 


A  new  start  is  a  program  not  previously  justified  and  appropriated  by  Congress  through  the  normal  budget 
process. 
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1 .4  Approach 


In  researching  this  report,  interviews  were  conducted  with  key  government  and  contractor  support 
personnel  from  the  represented  project  offices  that  were  responsible  for  milestone  preparation  and 
active  briefing  of  key  government  official  decision  makers.  Information  was  also  extracted  from 
after  action  reports,  articles  published  in  acquisition  periodicals,  and  lessons  learned  reports.^ 

1.5  Audience 

This  document  is  focused  on  the  needs  of  the  PEO  Aviation  and  its  project  offices,  but  also  has 
application  to  all  Department  of  Defense  (DoD)  acquirers,  a  community  that  typically  acquires 
software-intensive  systems.  It  is  believed  that  the  lessons  learned  information  is  applicable  regard¬ 
less  of  the  type  of  system  being  acquired. 

1.6  How  to  Use  the  Lessons  Learned  in  this  Document 

Section  2,  Lessons  Learned,  is  organized  by 

•  functional  area  context  (e.g.,  logistics) 

•  a  table  of  program  observations  and  lessons  learned  checklist  for  milestone  preparation 

•  source  selection  and  evaluation  lessons  learned 

The  lists  were  compiled  from  the  interviews  and  extraction  of  processes  and  activities  from  both 
the  lessons  learned  and  after  action  reports.  These  lists  will  be  useful  during  preparation  and  par¬ 
ticipation  in  briefings  and  milestone  reviews. 


The  government  decision  makers  were  members  of  the  Department  of  Defense/Army. 
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2 


Lessons  Learned 


2.1  General  Lessons  Learned 

The  observations  included  in  this  subsection  (Section  2.1)  do  not  fit  within  a  particular  domain. 
However,  since  they  are  overarching  and  foundational  to  the  remaining  content  in  this  report,  they 
are  sufficiently  important  to  include  here. 

When  doing  concurrent  staffing  with  milestone  documents,  which  are  all  moving  toward  review 
at  different  speeds,  it  is  easy  for  processes  to  get  out  of  sync.  As  you  move  forward,  it  is  important 
to  keep  these  processes  synchronized.  A  -Smart  Book”  is  a  key  tool  for  briefing  Army  leadership 
and  tracking  changes  over  time. 


Lessons  Learned  Checklist 

Program  Observations 

□ 

Experience  and  maturity  are  the  key  qualifiers  for  staffing  and 
keeping  it  small. 

The  first  job  for  the  new  team 
was  to  assemble  the  necessary 
personnel  to  staff  the  new 

PMO. 

□ 

Teams  should  have  multi-functional  area  capability. 

The  team  of  30  shared  several 
key  traits:  driven  desire  and 
focus  to  support  the  soldier, 
ability  to  multi-task,  a  mature 
demeanor,  10-plus  years  of 
experience  in  their  functional 
areas,  and  a  willingness  to 
work  long  hours  and  travel. 

□ 

Keep  processes  in  sync  on  concurrent  staffing  of  milestone  doc¬ 
uments  moving  at  varying  speeds.  At  times  achieving  total  docu¬ 
ment  synchronization  may  prove  impossible.  Identify  the  pro¬ 
gram’s  critical  pacing  documents  and  concentrate  efforts  on 
these  documents. 

Maintain  a  Smart  Book  or  a 
consistent  set  of  slides.  As  you 
make  changes  and  decisions 
quickly,  it  is  important  to  update 
these  slides. 

□ 

Overcome  resistance  by  developing  allies  and  engaging  with 
them  often.  Find  those  allies  who  have  issues  and  engage  them 
directly  (one-on-one).  Provide  sufficient  information  when  briefing 
primary  staff  elements,  Army,  and  the  Office  of  the  Secretary  of 
Defense  (OSD). 

Despite  repeated  efforts  to 
highlight  this  with  Army  leader¬ 
ship,  we  did  not  have  a  dedi¬ 
cated  Department  of  the  Army 
staff  coordinator  (DASC).  The 
DASC  performs  many  func- 

□ 

Fully  engage  with  the  OSD  staff  to  improve  communication  and 
establish  and  maintain  rapport. 

tions,  including  serving  as  the 
acting  deputy  in  the  Assistant 
Secretary  of  the  Army  (Acquisi¬ 
tion,  Logistics,  and  Technology) 
(ASA(ALT))  organization. 

□ 

From  the  very  beginning,  work  to  ensure  that  a  DASC  at  the  Ar¬ 
my  level  is  assigned  to  your  program. 
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Lessons  Learned  Checklist 


Program  Observations 


□  Track  critical  decisions  so  that  continuous  impact  is  made  during 
the  process  and  leadership  remains  informed. 


□  Cross-walk  all  Key  Performance  Parameters  (e.g.,  survivability 
and  force  protection)  from  the  capability  development  document 
(CDD)  to  other  salient  Milestone  B  documents  (e.g.,  the  acquisi¬ 
tion  strategy  report,  test  and  evaluation  master  plan).  This  will 
help  you  to  comply  with  the  Joint  Capabilities  Integration  and 
Development  System  (JCIDS)  process. 


□ 


Conduct  working  integrated  product  team  (WIPT)  meetings  at 
least  every  six  months.  Integrating  integrated  product  teams 
(IIPTs)  and  overarching  integrated  product  teams  (OIPTs)  will  be 
convened  as  requested  by  OSD  to  inform  new  OSD  personnel 
and  overcome  “decay  rate”  in  OSD’s  understanding  of  the  pro¬ 
gram. 


□ 


Conduct  recurring  WIPTs  to  brief  new  attendees  on  salient  as¬ 
pects  of  the  acquisition  strategy  and  program  schedule.  Acquisi¬ 
tion  strategy  report  (ASR)  changes  (e.g.,  lot  configuration  differ¬ 
ences  and  time  between  lots  facilitating  desired  operational  test 
events)  should  be  briefed  to  Army  Test  and  Evaluation  Command 
(ATEC)  and  the  Deputy  Under  Secretary  of  the  Army  for  Opera¬ 
tions  Research  (DUSA-OR)  leadership  prior  to  requesting  Direc¬ 
tor  of  Operational  Test  and  Evaluation  (DOT&E)  acceptance. 


□ 


Pre-brief  the  high-ranking  officers  in  G-8,  G-3,  ASA(ALT)  and  the 
Joint  Chiefs  of  Staff  Functional  Capabilities  Board  (JCB)  (part  of 
pre-Joint  Requirements  Oversight  Council  [JROC]  briefing  path). 
Especially  crucial  are  briefings  to  high-ranking  members  of  the 
Defense  Acquisition  Board  (DAB)  who  may  not  have  prior  under¬ 
standing  of  your  program  from  a  macro  point  of  view. 


□ 


Conduct  senior  officer  briefings.  These  briefings  are  critical  to 
ensure  acquisition  program  baseline  (APB)  and  Joint  Require¬ 
ments  Oversight  Council  memorandum  (JROCM)  approval  of  the 
CDD  are  in  synchronization  at  Milestone  B  in  order  to  sign  an 
acquisition  decision  memorandum  (ADM)  and,  more  importantly, 
a  System  Development  Demonstration  (SDD)  contract.  Doing  this 
will  avoid  work  stoppages  at  the  contractor’s  production  line. 


□ 


Maintain  continuous  interaction  with  OSD  AT&L  Land  Warfare; 
this  is  extremely  important  since  this  organization  is  involved  with 
numerous  programs. 
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Lessons  Learned  Checklist 


Program  Observations 


□ 


Continuously  coordinate  to  prevent  decay  rate  in  understanding 
the  various  aspects  of  a  new  program.  This  is  critical  for  a  pro¬ 
gram  that  is  undergoing  a  decision  review.  To  keep  functional 
experts  in  lock-step  with  the  SDD  phase  leading  to  Milestone  C,  it 
is  crucial  to  coordinate  among  Army  and  OSD  Office  of  the  Gen¬ 
eral  Counsel,  Policy,  and  DOT&E  officials. 


The  Army  Deputy  Chief  of  Staff  (G8,  Program  Analysis  and  Eval¬ 
uation)  and  the  OSD  Cost  Analysis  Improvement  Group  (CAIG) 
must  validate  affordability  assessments,  including  20-year  opera¬ 
tion  and  support  (O&S)  cost  estimates,  which  should  be  reflected 
in  the  Army  cost  position.  Test  and  evaluation  master  plan 
(TEMP),  cost  estimates,  and  policy  issues  are  symbiotic  in  that  a 
change  in  one  area  will  produce  a  profound  effect  on  a  different 
functional  area. 
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2.2  Programmatic  Lessons  Learned 


The  APB  outlines  how  the  system  will  be  procured  and  maintained  throughout  its  life  cycle.  It 
contains  a  synopsis  of  many  of  the  other  documents  that  are  developed  for  the  milestone  decision. 
The  APB  is  developed  after  most  of  the  other  documentation  is  finalized;  however,  it  must  be 
prepared  before  system  development  and  demonstration,  production  and  deployment,  and  full  rate 
production. 

A  program’s  acquisition  strategy  outlines  the  business  and  technical  management  approaches  that 
are  designed  to  achieve  program  objectives  within  the  resource  constraints  imposed.  Pursuant  to 
Army  Regulation  (AR)  70-1,  the  acquisition  strategy  is  based  upon  an  approved  requirement  (e.g.. 
Capability  Development  Document,  Capability  Production  Document).  The  acquisition  strategy 

•  is  the  framework  for  planning,  directing,  contracting  for,  and  managing  a  program 

•  outlines  activities  that  are  essential  for  program  success,  including  a  master  schedule  for  re¬ 
search,  development,  test,  production,  fielding,  modification,  post-production  management 
(i.e.,  sustainment),  and  demilitarization 

The  Acquisition  Strategy  Report  is  a  recurring  report  that  keeps  higher  management  appraised  of 
the  execution  of  the  program  acquisition  strategy. 


Lessons  Learned  Checklist  Program  Observations 

□ 

Ensure  that  all  points  of  contact  (POCs)  are  aware 
when  new  versions  of  the  APB  are  distributed. 

Final  estimates  for  funding  requirements 
in  the  Army  cost  position  differed  greatly 
from  the  initial  budget  profiles  developed 
in  the  Analysis  of  Alternatives  (AoA)  and 
from  market  research.  Keeping  the  G8  in 
the  loop  throughout  the  budget  process, 
as  a  member  of  the  Army  Cost  Review 
Board  (CRB),  enabled  the  Army  to  per¬ 
form  the  required  affordability  analysis  in 
a  timely  manner  and  identify  reprogram¬ 
ming  actions  that  addressed  specific 
funding  shortfalls.  This  prevented  poten¬ 
tial  unfavorable  affordability  assessments 
later  in  the  Milestone  Review  process. 

□ 

Provide  updates  for  the  APB  in  the  cost  analysis  report¬ 
ing  system  file.  Do  this  for  everything,  including  initial 
staffing. 

□ 

When  restructuring  ASRs,  be  careful  not  to  use  the 
same  level  of  detail  from  Milestone  B  since  this  ap¬ 
proach  will  not  work. 

What  does  the  ASR  reflect?  At  Milestone 

B  and  the  Restructure,  the  ASR  reflected 
only  a  general  acknowledgement  that  a 
follow-on  program  was  allowed  in  the 

ASR.  At  Milestone  C,  the  expectation  was 
changed  to  reflect  greater  detail.  This 
caused  one  of  the  first  major  rewrites 
when  we  used  the  same  level  of  detail 
from  the  Milestone  B  and  Restructure 
ASRs. 

□ 

Staff  the  APB  and  ASR  at  the  same  time — even  if  you 
refer  to  the  OSD  version  as  read-ahead.  The  faster  they 
get  the  document,  the  sooner  they  will  provide  com¬ 
ments. 
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Lessons  Learned  Checklist  Program  Observations 

□ 

Ensure  that  the  contract  for  the  APB  should  be  well 
defined. 

The  AP\B  is  a  contract  between  the  PM 
and  the  defense  acquisition  executive 
(DAE)  regarding  cost,  schedule,  and  per¬ 
formance  of  the  system  being  acquired. 

□ 

Ensure  that  prospective  budget  profiles  are  provided  to 
the  DCS  G8  at  all  stages  of  the  program.  This  will  ena¬ 
ble  the  Army  to  perform  required  affordability  analysis  in 
a  timely  manner  and  identify  reprogramming  actions 
that  address  specific  funding  shortfalls. 

Providing  prospective  budget  profiles  to 
DCS  G8  at  all  stages  of  the  program  may 
enable  the  Army  to  perform  required  af¬ 
fordability  analysis  in  a  timely  manner  and 
identify  reprogramming  actions  that  ad¬ 
dress  specific  funding  shortfalls. 
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2.3  Documentation  Lessons  Learned 


Context 

As  part  of  the  milestone  review  budget  process,  the  PMO  prepares  the  Cost  Analysis  Require¬ 
ments  Document  (CARD)  and  Program  Office  Estimate  (POE),  the  Deputy  Assistant  Secretary  of 
the  Army  for  Cost  and  Economics  prepares  a  Component  Cost  Analysis  (CCA),  and  OSD  CAIG 
prepares  an  Independent  Cost  Estimate  (ICE).  Army  Cost  Position  (ACP)  provides  an  analysis  of 
the  cost  risk  area;  technical,  schedule,  and  requirements  creep;  and  cost-estimating  uncertainty. 
These  documents  require  sufficient  data  to  accurately  estimate  the  cost  of  each  alternative  plat¬ 
form  and  reflect  the  risk  confidence  levels. 


Lessons  Learned  Checklist  Program  Observations 

□ 

Sanitize  the  CARD,  POE,  CCA,  and  ACP  data  to 
avoid  disclosing  the  proposed  approach  of  each 
offeror  and  the  number  of  proposals.  This  can  be 
accomplished  by  using  codes  for  the  offerors 
and  including  additional  platforms  so  that  it  is  not 
possible  to  identify  the  offerors. 

To  avoid  disclosing  the  proposed  approach  of 
each  offeror  and  the  number  of  proposals,  the 
CARD,  POE,  CCA,  and  ACP  should  use  sani¬ 
tized  data  for  each  alternative  platform  and  in¬ 
clude  data/estimates  for  additional  platforms  in 
the  marketplace. 

□ 

Use  the  Defense  Acquisition  University  website, 
which  provides  useful  information  on  all  aspects 
of  reporting  requirements,  including  integrated 
baseline  reviews,  EVMS,  and  new  program  start¬ 
up  workshops. 

It  is  difficult  to  anticipate  the  documentation 
timelines  that  are  necessary  to  “get  a  pass”  from 
some  organizations,  such  as  the  CAIG  and 
DOT&E. 

□ 

Manage  as  effectively  as  possible  considering 
that  key  players  continually  change. 

Due  to  the  length  of  the  process,  the  Apache 

Block  III  (AB3)  specific  knowledge  “decay  rate” 
or  organizational  “face  changes”  caused  numer¬ 
ous  re-briefs.  We  were  often  revisiting  previously 
closed  issues  because  a  key  player  was 
changed  within  the  process  chain. 

□ 

Estimate  the  time  involved  in  developing  and 
coordinating  key  documents. 

Document  approvals  accounted  for  the  greatest 
PMO  resource  investments.  Key  documents 
included: 

•  Capabilities  Development  Document 

•  Acquisition  Strategy  Report 

•  Test  and  Evaluation  Management  Plan 

•  Systems  Engineering  Plan  (SEP) 

•  Independent  Life-Cycle  Cost  Estimate 

•  Technology  Readiness  Assessment  (TRA) 

•  Information  Support  Plan  (ISP)  (Clinger  Cohen 
Act  compliance) 
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Lessons  Learned  Checklist  Program  Observations 

□ 

Invest  the  time  to  brief  key  Pentagon  personnel 
to  secure  their  support  in  programming  dollars. 

Repeated  trips  to  Washington  to  brief  the  G8 
and  Army  Budget  Office  personnel  are  time  con¬ 
suming.  However,  during  program  objective 
memorandum  (POM)  development  activities, 
champions  were  secured  for  the  Small  Un¬ 
manned  Air  Vehicle  program.  This  ensured  daily 
contact  with  key  personnel  and  offices  within  the 
Pentagon. 

□ 

Start  early  to  understand  the  layout  and  com¬ 
plexities  of  the  required  information,  interopera¬ 
bility  requirements,  and  the  best  means  for  coor¬ 
dinating  documents.  Lead  time  is  needed  to 
accomplish  all  required  briefings,  documentation, 
meetings,  and  decision  reviews. 

Special  attention  is  required  when  dealing  with 
Army  information  and  interoperability  coordina¬ 
tion  and  documentation.  This  is  driven  by  the 
fact  that  Army  information  is  fragmented  across 
Headquarters,  Department  of  the  Army  (HQDA). 
Also,  information  activities  can  be  found  in  dis¬ 
parate  groups,  each  requiring  their  own  unique 
information  as  follows. 

•  G-3  Information  Requirements 

•  G-6  Acquisition  Compliance  and  Certification 

•  G-6  Frequency  Spectrum  Division-NETCOM 

•  G-6  Architecture  Operations  Network  and 

Space 

□ 

Pay  special  attention  to  the  effects  that  JTRS 
may  have  on  information  documentation.  Avoid 
holding  one  program  hostage  based  on  another 
program’s  development  success. 

The  impending  Joint  Tactical  Radio  System 
(JTRS)  program  had  a  profound  effect  on  the 
Apache  Block  III  (AB3)  Information  documenta¬ 
tion.  Army  and  OSD  G-6  officials  used  the  pro¬ 
gram  as  the  “pioneer”  to  improve  interoperability 
expected  to  be  filled  by  JTRS  when  that  pro¬ 
gram  reaches  maturity.  JTRS  program  turbu¬ 
lence  generated  a  “Moderate  Risk”  for  the  AB3 
program  Net  Ready  Key  Performance  Parame¬ 
ter  (KPP). 
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2.4  Army  Systems  Acquisition  Review  Councii  (ASARC)  and  Defense  Acquisition 
Board  (DAB)  Processes  Lessons  Learned 

The  Amy  Systems  Acquisition  Review  Council  (ASARC)  is  the  Amy-level  review  body  for 
acquisition  of  all  ACAT  I/IA  programs  and  other  select  programs  where  the  Amy  Acquisition 
Executive  (AAE)  is  the  Milestone  Decision  Authority  (MDA).  The  ASARC  provides  a  structured 
forum  where  issues  requiring  top-level  consideration  are  presented  to  senior  Army  leadership. 
DODD  5000.1,  DODI  5000.02,  and  AR  70-1  govern  the  Amy’s  milestone  review  process.  The 
DAB  and  Information  Technology  Acquisition  Board  (ITAB)  are  OSD-level  forums  that  operate 
in  much  the  same  manner  as  the  ASARC.  The  DAB/ITAB  and  the  ASARC  differ  in  the  level  of 
their  respective  memberships  and  the  ACAT  level  of  the  programs  they  review. 

The  ASARC,  DAB,  and  ITAB  are  advisory  bodies.  The  council/board  recommendations  are  con¬ 
veyed  to  the  respective  MDA  for  final  decision.  In  the  majority  of  cases,  the  MDA  is  present  dur¬ 
ing  these  reviews,  which  preclude  additional  reviews.  The  ASA(ALT)  chairs  the  ASARC;  the 
DAB  and  ITAB  are  chaired  by  the  Under  Secretary  of  Defense  for  Acquisition,  Technology  and 
Logistics  (USD(AT&L)). 


Lessons  Learned  Checklist  Program  Observations 

□ 

Maintain  proper  communication  in  an  effort  to  keep  the  new 
members  educated.  This  is  important  because  of  the  frequent 
rotation  of  military  staffers. 

DA  and  OSD  staff  members  do  a 
pretty  good  job  of  assigning  repre¬ 
sentatives  to  the  programs.  How¬ 
ever,  due  to  rotations — especially 
among  military  members — the  PM 
is  constantly  educating  the  staff 
members. 

□ 

Tailor  and  waiver — reduce  the  workload.  Success  requires 
engaging  the  stakeholders  to  make  them  part  of  your  tailoring. 

Due  to  workload,  staff  members 
cannot  always  remain  current  on 
the  status  of  the  particular  pro¬ 
gram. 

□ 

Bring  your  “A”  team  to  Washington  to  work  on  issues  in  real 
time.  Build  the  team  to  include  the 

•  business  person  (e.g.,  contracts,  comptroller,  legal) 

•  test  person,  especially  important  in  terms  of  your  production 
decisions 

•  programmatics 

OSD  AT&L  staff  members  are  re¬ 
luctant  to  conduct  IIPT  meetings 
early  in  the  process  because  they 
can  be  time  consuming.  At  the 
same  time  they  want  to  “socialize” 
staff  members  to  strategies  and 
issues  and  their  solutions  at  the 
last  minute,  when  there  is  little  time 
to  affect  change. 

The  Army  Systems  Acquisition 
Review  Council  (ASARC)  secretary 
helps  to  get  things  through  the  mili¬ 
tary  department  (MILDEP)  and  the 
Army  Acquisition  Executive  (AAE). 

□ 

Attempt  to  discuss  approval  criteria  at  a  high  level  of  concur¬ 
rence.  Avoid  micro-managing  minor  issues  (although  this  is 
sometimes  impossible). 

□ 

Take  related  documentation  (e.g.,  briefing  charts)  with  you. 

□ 

Build  Smart  Books  to  facilitate  preparation  for  briefings  to  the 
AAE  and  DAE  regarding  the  decision  to  build  new  in  lieu  of 
remanufacture. 
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Lessons  Learned  Checklist  Program  Observations 

□ 

Maintain  a  Smart  Book  that  contains  the  latest  position  papers 
and  key  documents.  Take  the  Smart  Book  with  you  to  briefings 
so  that  when  questions  surface  you  will  have  access  to  key 
documentation  that  shows  the  full  history. 

□ 

Hold  IIPTs  frequently  enough  to  ensure  that  team  members 
are  kept  up  to  date. 

□ 

Keep  comprehensive  minutes  of  the  meetings,  even  if  you 
simply  record  brief  memos.  Complete  the  notes  soon  after  the 
meeting  and  get  them  staffed  within  the  PM  as  soon  as  possi¬ 
ble.  Store  the  minutes  where  they  can  be  found  easily. 

□ 

Identify  OSD  subject  matter  experts  early  and  establish  good 
relations  with  them  since  they  will  help  to  streamline  the 
process. 

□ 

PM  IPT  leads  and  leadership  must  make  contact  with  DA  and 
OSD  staffers;  this  is  particularly  true  in  the  documentation 
phases.  If  a  document  author  stays  engaged  with  the  staffer, 
there  will  be  fewer  problems  during  documentation  signoff. 

□ 

Resource  your  staff.  The  DASC  cannot  do  everything.  You  will 
be  working  on  a  contract  and  getting  a  milestone  decision 
along  with  doing  the  day-to-day  operations  of  creating  a  sys¬ 
tem.  You  must  have  the  depth  and  breadth  to  accomplish 
these  tasks  concurrently.  If  you  don’t,  you  must  either  stretch 
your  decision  time  or  accept  risk. 

□ 

Maintain  healthy  communication  so  that  processes  run 
smoothly.  The  PM  and  his  staff  must  push  the  OSD  and  DA 
staff  for  concurrence  and  communication. 

Lack  of  communication  is  a  signifi¬ 
cant  problem.  For  many  reasons, 
the  staff  officer  and  his  or  her  prin- 
cipal  often  do  not  communicate. 

Information  flow  is  fragmented 
across  HODA  with  disparate 
groups  requiring  their  own  unique 
information  such  as 

•  G-3,  Information  Requirements 

•  G-6,  Acquisition  Compliance  and 
Certification 

•  G-6,  Frequency  Spectrum 

Division 

•  G-6,  Architecture  Cperations 
Network  and  Space 

Weekly  telephone  conferences  with 
PMC,  DASC,  Training  and  Doctrine 
Command  (TRADCC)  System 
Manager  (TSM),  ATEC  proved  to 
be  helpful  in  terms  of  status  docu¬ 
ment  approvals  and  upcoming  re¬ 
view  coordination. 

□ 

Keep  a  record  of  each  problem  and  how  it  was  resolved;  con¬ 
sider  recording  the  information  in  a  Smart  Book.  Carry  this 
information  with  you  so  that  if  someone  has  a  related  question, 
you  will  be  prepared  to  formulate  an  answer. 

□ 

Stay  in  close  communication  with  the  G-8,  Force  Development 
and  the  G-3,  Aviation  Task  Force.  These  groups  are  at  the 
center  of  Army  aviation  and  they  will  support  you  through  the 
process. 

□ 

Appoint  an  ASARC  coordinator  to  serve  as  focal  point  in  the 

PM.  This  is  the  person  who  keeps  a  finger  on  the  pulse  of  the 
program  and  ensures  that  the  word  gets  to  the  DASC,  the  CSD 
AT&L  staff,  and  the  DA  ASARC  secretary. 

CMU/SEI-2010-TR-006  |  11 


Lessons  Learned  Checklist  Program  Observations 

□ 

Investigate  having  the  Systems  Engineering  and  Technical 
Assistance  (SETA)  contractor  help  you  by  providing 

•  facilities  for  use  as  a  home  base  or  meetings 

•  support  in  preparing  items  such  as  briefings  and  white  pa¬ 
pers 

•  backup  information  during  the  meeting  or  briefings 

The  SETA  contractor  is  not  always 
accepted  by  the  DA  and  OSD 
staffs.  The  PM  and  his  government 
staff  are  expected  to  know  their 
program,  maintain  awareness  of 
the  issues,  and  be  able  to  brief  the 
program.  AB3  coordinated  DASC 
sponsorship  for  key  SETA  con¬ 
tracts;  that  enabled  “no  escort  re¬ 
quired”  badges  to  be  issued  in  the 
Pentagon. 

□ 

When  facing  the  challenge  of  executing  a  complex  moderniza¬ 
tion  program,  preplanning  is  the  key  to  success. 

Justifying  and  defending  an  exten¬ 
sive  modernization  program  is 
highly  complex  and  requires  sound 
preplanning. 

□ 

Begin  any  future  endeavors,  such  as  “Beyond  AB  III”  or  “Block 
IV,”  in  earnest  at  least  four  years  prior  to  the  projected  Miles¬ 
tone  Decision  date.  This  lead  time  is  necessary  to  accomplish 
the  required  briefings,  documents,  meetings,  and  decision  re¬ 
views  that  are  required  to  obtain  OSD  approval. 

Because  of  the  Net  Ready  KPP 
dependencies,  JTRS  program  tur¬ 
moil  affected  AB3  Milestone  B  in¬ 
formation  and  documentation 
processes. 
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2.5  Logistics  and  Support  Lessons  Learned 


The  core  depot  analysis  is  a  business  case  analysis  to  determine  where  depot-level  repairables 
should  be  made. 

The  Manpower  Estimate  Report  (MER)  is  used  to  help  inform  various  manning  decisions,  cost 
estimates,  and  affordability  of  the  program.  (For  more  information  about  this,  see  Title  10  USC 
2434,  DODI  5000.2,  DA  PAM  70-3.)  The  entire  process  typically  takes  about  eight  months,  but  it 
might  take  longer  if  you  are  starting  with  a  system  that  does  not  exist  or  one  that  will  not  replace 
an  existing  system. 

Program  managers  are  responsible  for  laying  out  and  executing  a  strategic  blueprint  (i.e.,  Suppor- 
tability  Statement)  for  the  logistics  process  so  that  every  part  of  the  package  is  integrated  and  con¬ 
tributes  to  the  warfighter’s  mission  capability. 

AR  70-47  and  DA  PAM  70-3  require  Transportability  Reports  to  be  conducted  on  all  systems. 
These  reports  outline  the  assessment  of  the  system’s  ability  to  be  transported  on  the  systems  iden¬ 
tified. 

The  system  training  plan  (STRAP) — ^required  by  DoDD  1430.13,  DoD  5000.2-R,  and  DA  PAM 
70-3 — describes  how  users  will  be  trained  on  the  system.  The  STRAP  is  generated  by  TRADOC 
and  must  be  approved  at  TRADOC  headquarters  in  conjunction  with  the  requirements  document. 


Lessons  Learned  Checklist 


Program  Observations 


□  Articulate  all  facts  and  assumptions  clearly  and  use  them  consistent¬ 
ly  during  the  core  analysis. 


□  Staff  the  initial  draft  of  the  supportability  strategy  as  soon  as  possible 
within  the  Logistics  IPT  working  group. 


□ 


Update  the  basis  of  issue  plan  (BOIP)  at  every  milestone. 


Including  performance- 
based  logistics  (PBL)  re¬ 
quirements  in  all  planned 
contracting  efforts  was  criti¬ 
cal. 

Supportability/sustainment 
planning  must  be  outlined 
by  performance-based 
goals,  metrics,  and  demon¬ 
strated  progress. 


It  is  essential  to  have  con¬ 
tractor  data  for  new  items. 
The  analyst  must  have  the 
contractor’s  rationale  and 
data  for  determining  that  the 
item  is  a  depot-level  repair¬ 
able.  If  the  contractor  did  not 
perform  a  level  of  repair 
analysis,  he  or  she  must 
make  additional  assump¬ 
tions  that  increase  the  risk 
of  error  to  the  study. 
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Lessons  Learned  Checklist 

Program  Observations 

□ 

Ensure  that  there  are  quantifiable  supportability  metrics  for  all  phas¬ 
es  of  planning  and  execution. 

OSD  Logistics  and  Materiel 
Readiness  (LM&R)  empha¬ 
sized  logistics  planning  and 
supportability. 

□ 

Identify  potential  problems  with  getting  the  MER  staffed  and  ap¬ 
proved.  It  is  often  difficult  to  find  someone  who  wants  to  own  the 

MER. 

Supportability  was  not  an 
afterthought. 

It  was  extremely  difficult  to 
get  comments  on  the  sup- 
portability  statement. 

□ 

Update  the  systems  engineering  slide  to  include  logistics  supporta¬ 
bility,  and  add  a  special  interest  item  slide  to  include  information 
about  items  such  as  corrosion  prevention/control  and  unique  identifi¬ 
cation. 

□ 

Communicate  via  the  IPTs  (e.g.,  telephone  and  email)  that  the  doc¬ 
ument  is  forthcoming.  This  is  key  to  successful  staffing  of  the  sup- 
portability  statement. 

□ 

Coordinate  the  STRAP  with  all  stakeholders  to  ensure  that  all  data 
items  are  correct. 

The  STRAP  is  developed  by 
the  Directorate  of  Training, 
Doctrine  and  Simulation  at 
United  States  Army  Aviation 
Center  (USAAVNC).  The 
STRAP  is  not  coordinated 
with  the  maintenance  coun¬ 
terparts  at  the  United  States 
Army  Aviation  Center  in  Ft. 
Lee.  Therefore,  the  main- 
tainer  training  and  training 
device  information  may  not 
be  correct. 

□ 

Coordinate  logistics  supportability  documents  with  both  the  Secre¬ 
tary  for  Acquisition  and  Systems  Management  (SAAL)  ILS  and  G-4 
(Aviation  Log  Division).  Examples  of  such  documents  are  the  AB3 
supportability  strategy  report  and  the  item  unique  identification  plan. 

Logistics  supportability  doc¬ 
uments  (e.g.,  the  AB3  sup¬ 
portability  strategy  report 
and  item  unique  identifica¬ 
tion  plan)  should  be  coordi¬ 
nated  with  the  Deputy  Assis¬ 
tant  Secretary  for 

Acquisition  Policy  and  Lo¬ 
gistics  ILS  and  G-4  (Aviation 
Log  Division).  OSD  LM&R 
analysts  are  proactive  once 
they  receive  these  docu¬ 
ments. 
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Lessons  Learned  Checklist  Program  Observations 

□ 

Adhere  strictly  to  the  total  life-cycle  systems  management  concept; 
this  will  lower  the  risks  of  sustainability.  Developing  a  supportability 
plan  early  on  and  getting  concurrence  from  the  stakeholders  is  criti¬ 
cal  to  operation  and  sustainment  success. 

It  is  no  use  to  field  a  wea¬ 
pons  system  that  is  not  sup¬ 
portable  and  sustainable.  A 
supportable  and  sustainable 
system  takes  detailed  plan¬ 
ning  up  front  and  implemen¬ 
tation  throughout  the  life 
cycle.  This  is  the  intent  of 
total  life-cycle  systems 
management  concept. 

□ 

Establish  measures  with  appropriate  indicators  that  will  satisfy  OSD 
LM&R. 

Improved  Block  III  suppor¬ 
tability  needed  quantifiable 
metrics  per  OSD  LM&R. 
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2.6  Technical/Engineering  Lessons  Learned 


Joint  Technical  Architecture  (JTA)  is  a  common  set  of  mandatory  information  technology  stan¬ 
dards  (primarily  interface  standards)  and  guidelines.  The  JTA  should  be  used  by  all  emerging  sys¬ 
tems  and  systems  upgrades,  including  advanced  concept  technology  demonstrations.  The  JTA  can 
be  used  to  establish  a  system’s  technical  architecture,  and  is  applicable  to  all  command,  control, 
computing,  communication,  and  intelligence  (C4I)  and  automated  information  systems  and  inter¬ 
faces  of  other  key  assets  (e.g.,  weapons  systems,  sensory)  with  C4I  systems. 

The  JCIDS  process  determines  the  requirements  for  the  military,  and  as  of  March  2004,  is  go¬ 
verned  by  the  Joint  Chiefs  of  Staff  Instruction  (CJCSI)  3 170.01C.  The  JCIDS  document  serves  as 
the  Operational  Requirements  Document  (ORD)  and  answers  the  question  — Wy  do  you  need  the 
system?” 

The  Information  Support  Plan  (ISP)  strategy  identifies  the  information  technology  (including  na¬ 
tional  security  systems)  infrastructure  enhancements  that  are  required  to  support  program  execu¬ 
tion.  The  ISP  should  identify  technical,  schedule,  and  funding  issues  that  are  in  the  critical  path 
and  that  could  affect  the  execution  of  the  acquisition  strategy  in  the  infrastmcture  for  the  acquisi¬ 
tion  program  and  the  information  technology  (including  national  security  systems).  The  acquisi¬ 
tion  strategy  then  synopsizes  the  shortfalls  and  issues,  and  devises  plans  to  resolve  them. 


Lessons  Learned  Checklist  Program  Observations 

□ 

Interface  frequently  with  the  Weapons  Systems  Tech¬ 
nical  Architecture  Working  Group  JTA-A 
(WSTAWG/JTA-A);  doing  so  will  help  you  to  resolve 
problems  successfully. 

The  JTA  mandate  was  relatively  new 
during  the  initial  development  of  the  UH- 
60M;  many  PMs  struggled  to  understand 
the  process  by  which  the  JTA-A  com¬ 
pliance  was  to  be  demonstrated  and  who 
would  eventually  make  the  final  determi¬ 
nation  of  compliance.  Through  close 
partnership  with  other  PMs  and  Aviation 
and  Missile  Command  (AMCOM)/PEO 
assistance,  and  by  having  a  good  work¬ 
ing  relationship  with  the  Army  Systems 
Engineering  Office  (ASEO),  these  issues 
were  eventually  overcome  and  the 
process  was  successfully  concluded. 

□ 

Maintain  the  JTA-A  as  a  dynamic  document.  It  is  impor¬ 
tant  to  stay  abreast  of  existing  specifications  that  could 
be  under  consideration  for  enactment  or  sunsetting. 

Since  the  JTA-A  is  a  living  document,  it  is 
reviewed  and  modified  periodically.  Un¬ 
fortunately  the  review  process  can  have 
unintended  effects.  For  example,  during 
[this]  program  execution  a  specification 
sunset  clause  went  into  effect;  the  clause 
threatened  to  eliminate  most  of  the  lega¬ 
cy  interface  specifications  used  by  Army 
aviation  platforms. 
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Lessons  Learned  Checklist  Program  Observations 

□ 

Since  the  G-6  reviews  are  processed  slowly,  it  is  critical 
to  maintain  contact  with  someone  in  G-6  so  that  they 
can  skillfully  push  the  process  along. 

The  compliance  matrix  and  associated 
three  waivers  were  submitted  to  ASEO 
for  prescreening,  before  being  submitted 
to  G-6  for  final  approval.  While  ASEO 
was  satisfied  and  assured  the  PMO  that 
the  documents  were  in  good  order  and 
ready  to  be  submitted,  the  G-6  review 
process  was  slow.  This  was  due  to  an 
extensive  backlog  at  G-6,  which  made  it 
difficult  to  contact  anyone  and  obtain 
meaningful  status  reports.  The  approval 
from  G-6  took  almost  a  full  year  and  ar¬ 
rived  just  in  time  for  the  UH-60M  Miles¬ 
tone  C  review. 

□ 

Stay  current  on  J-6  guidance  with  regard  to  Net  Ready 
KPPs  since  this  guidance  could  impact  the  ORD  ap¬ 
proval  process. 

Our  ORD  was  delayed  because  of  the 
requirement  to  include  a  Net  Ready  KPP 
and  its  associated  pieces,  which  were 
dictated  by  CJCSI  6212.010  when  it  was 
implemented  in  2004.  This  represented  a 
significant  change  from  the  previous  J-6 
guidance,  which  indicated  that  because 
this  was  a  new  requirement,  [the  pro¬ 
gram]  did  not  need  to  include  it  in  the 

ORD.  The  change  required  us  to  develop 
a  migration  approach  to  meeting  the  KPP 
and  develop  architectures  at  TRADOC. 

This  caused  significant  delays  in  the  ORD 
approval  process. 

□ 

Establish  close  coordination  with  NDII  and  OSD  As¬ 
sessments/Open  Systems  Architecture,  Science  and 
Technology;  they  will  provide  invaluable  program  sup¬ 
port  review. 

Apache  Block  III  received  invaluable  pro¬ 
gram  support  review  from  NDI  and  OSD 
Assessments/Open  Systems  Architecture, 
Science  and  Technology. 
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2.7  Test  and  Evaluation  Lessons  Learned 


The  purpose  of  the  Test  and  Evaluation  (T&E)  is  to  assess  system  progress  toward  operational 
effectiveness,  suitability,  and  survivability.  T&E  supports  the  system  development  and  acquisition 
process,  and  is  intended  to  provide  information  on  risk  identification  and  mitigation  to  Army  deci¬ 
sion  makers.  When  considering  a  system’s  programmatic  progress  throughout  its  development  life 
cycle  and  prior  to  major  milestone  decision  reviews,  risk  must  be  accounted  for  (in  concert  with 
cost,  schedule,  performance,  and  supportability).  Army  programs  are  structured  to  integrate  the 
developmental  test  (DT),  operational  test  (OT),  combined  DT/OT,  live  fire  test  and  evaluation 
(LFT&E),  system  evaluation,  and  Modeling  and  Simulation  (M&S)  as  a  continuum.  (For  more 
information  about  this,  see  DA  PAM  73—1,  Chapters  5  and  6.) 

The  System  Evaluation  Report  (SER)  is  developed  by  the  PM  and  presents  the  findings  of  the 
system  assessment/test.  The  SER  is  required  by  DODI  5000.2  and  provides  the  milestone  decision 
authority  assurance  that  the  system  is  suitable,  safe,  and  effective. 

The  MER  is  used  to  help  determine  manning  decisions,  cost  estimates,  and  affordability  of  the 
program.  The  entire  process  typically  takes  about  eight  months,  but  could  take  longer  if  you  are 
starting  with  a  system  that  does  not  exist  or  one  that  will  not  replace  an  existing  system.  (For  more 
information  about  this,  see  Title  10  USC  2434,  DODI  5000.2,  and  DA  PAM  70-3.) 


Lessons  Learned  Checklist  Program  Observations 

□ 

Develop  the  SER  early  and  be  specific  about  the  roles  and  re¬ 
sponsibilities  of  the  PMO  and  TRADOC. 

It  takes  about  three  months  for 
the  SER  to  be  completed  fol¬ 
lowing  the  end  of  testing.  [The 
program]  needed  to  talk  gener¬ 
ally  [about]  what  ATEC  does 
and,  specifically,  what  [the  pro¬ 
gram]  did  or  should  do  to  help 
the  process.  The  real  issue  is 
reliability. 

□ 

Develop  the  TEMP  as  early  as  possible. 

The  TEMP  is  the  key  document 
used  as  a  contract  among  all 
stakeholders  in  the  evaluation 
process.  Developing  a  TEMP 
must  be  a  priority  early  in  the 
program.  Early  involvement 
with  the  ATEC  community  is  a 
key  to  success. 

Assemble  a  T&E  WIPT  charter 
early.  The  charter  will  help  you 
to  identify  the  organizations 
with  which  you  should  interface 

□ 

Assemble  a  T&E  WIPT  charter  early.  The  charter  will  help  identify 
the  organizations  that  are  required  to  interface  with  its  develop¬ 
ment.  It  is  essential  to  have  clarity  of  roles  and  responsibilities. 

□ 

Divide  the  TEMP  into  sections  of  responsibility;  involve  outside 
organizations,  such  as  Central  Technical  Support  Facility,  Joint 
Interoperability  Test  Command,  and  the  threat  community.  En¬ 
sure  that  each  effort  has  a  funding  profile  for  Part  V  of  the  TEMP 
and  can  justify  the  profiles. 
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Lessons  Learned  Checklist  Program  Observations 

□ 

Use  Microsoft  Word’s  track  changes  feature  to  coordinate  up¬ 
dates.  This  will  speed  up  the  process  while  maintaining  a  record 
of  the  change  history.  Appoint  one  person  to  be  responsible  for 
consolidating  changes  and  maintaining  the  current  version. 

during  the  development  of  the 
TEMP. 

Since  there  are  many  key  doc¬ 
uments  that  directly  affect  the 
TEMP  (e.g.,  CDD,  critical  oper¬ 
ational  issues  and  criteria 
[COIC],  systems  threat  as¬ 
sessment  report),  it  is  important 
to  understand  the  staffing 
process. 

□ 

Make  TEMP  approval  a  priority.  Most  organizations  require  a 
specific  time  for  staffing,  and  they  will  take  their  time  based  on 
the  urgency.  However,  in  the  end,  everyone  will  work  to  approve 
the  TEMP  to  meet  the  DAB. 

□ 

Understand  the  staffing  process  since  there  are  many  key  docu¬ 
ments  that  directly  affect  the  TEMP  (e.g.,  CDD,  critical  operation¬ 
al  issues  and  criteria  [COIC],  systems  threat  assessment  report). 

□ 

Maintain  strict  configuration  control  over  the  TEMP.  Ensure  that 
everyone  involved  has  the  latest  version.  This  is  critical  because 
the  TEMP  requires  several  updates  as  it  evolves. 

□ 

Facilitate  approval  of  the  key  documents  as  required.  Make  sure 
the  documents  are  approved  prior  to  formal  TEMP  staffing 
through  DA. 

□ 

As  soon  as  the  program  is  established,  it  is  critical  to  identify 

•  an  ATEC  system  team  chair  from  the  Army  Evaluation  Center 

•  a  developmental  test  lead  from  Developmental  Test  Command 

•  an  operational  test  lead  from  Operational  Test  Command 

□ 

Work  closely  with  the  TSM  in  CDD  development  and  the  COIC 
process.  Do  a  requirements  crosswalk  to  test  the  program  to  as¬ 
sure  that  everything  has  been  addressed. 

□ 

Maintain  close  coordination  with  the  TSM.  This  will  help  to  ensure 
that  the  test  program  addresses  the  users’  needs. 
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2.8  Source  Selection  and  Evaluation  Lessons  Learned — Attack  Reconnaissance 
Helicopter  (ARH) 


Planning  for  the  Source  Selection  Evaluation  Board  (SSEB)  was  initiated  in  mid-October  2004 
with  an  SSEB  start  of  January  2005.  Planning  consisted  of  identifying  personnel  and  logistics  re¬ 
quirements  and  developing  training  media.  Multiple  in-process  reviews  were  held  internally  with¬ 
in  the  SSEB  management  team  to  ensure  that  the  plans  were  sound.  The  plans  were  briefed  to  the 
Source  Selection  Advisory  Council  (SSAC)  chairman  approximately  two  weeks  prior  to  the  SSEB 
start  to  obtain  approval. 

After  the  requirements  were  established  and  approved,  coordination  was  initiated  with  the 
AMCOM  Acquisition  Center  Facilities  POC  to  obtain  appropriate  facilities  for  the  team.  Between 
November  2004  and  early  January  2005,  four  initial  training  sessions  were  conducted.  The  goal  of 
these  meetings  was  to  provide  to  all  board  members  information  about  (1)  the  Army  Source  Se¬ 
lection  Guide,  (2)  the  source  selection  plan,  (3)  the  modified  process,  and  (4)  the  schedule. 

Three  days  prior  to  receiving  the  proposals  from  offerors,  follow-on  (secondary)  training  was 
provided  to  all  SSEB  members.  This  training  detailed  the  milestones/schedule  and  the  database 
system.  A  — uck  drill”  on  the  database  concluded  this  training  event  and  prepared  the  team  for 
proposal  receipt. 

One  set  of  offerors’  discussions  was  conducted  by  telephone  and  two  discussions  were  conducted 
in  person.  All  discussions  were  audiotaped  and/or  videotaped. 

The  organizational  leadership  structure  of  the  SSEB  included  a  chairman;  deputy;  operations  of¬ 
ficer  and  staff;  and  factor,  sub-factor,  and  element  leads.  Normally,  an  operations  officer  is  not 
utilized  in  an  SSEB;  however,  due  to  the  size  and  complexity  of  this  particular  SSEB,  it  was  de¬ 
termined  that  full-time  work  was  required  to  manage  personnel,  logistics,  and  day-to-day  and  fu¬ 
ture  operations  of  the  SSEB  proceedings.  Additionally,  having  an  operations  cell  allowed  the 
chairman  and  deputy  to  be  more  involved  in  the  technical  aspects  of  evaluations  with  the  pro¬ 
curement  contracting  officer  and  legal  advisor. 


The  source  selection  plan  was  approved  by  the  Source  Selection  Authority  (SSA)  in  November 
2004.  The  SSEB  chairman  was  brought  into  the  planning  in  mid-October — in  the  middle  of  the 
draft  request  for  proposal  (REP)  process — and  was  immediately  involved  in  the  revisions  of  the 
source  selection  plan.  Additionally,  the  chairman  served  as  a  primary  briefer  to  the  SSA  to  obtain 
approval  of  the  selection  plan. 

Lessons  Learned  Checklist  Program  Observations 


□ 


Obtain  written  authorization  to  use  the  Redstone 
Arsenal  facilities  and  ensure  that  the  director  or  dep¬ 
uty  director,  Acquisition  Center,  provides  approval. 
Ensure  that  there  is  significant  time  (two  to  three 
months)  between  when  one  SSEB  concludes  and 
another  one  begins. 


The  institution  of  a  full-time  operations  cen¬ 
ter  for  the  SSEB  increased  efficiency  in  the 
current  and  future  operations  of  the 
process. 

Physical  security  was  maintained  in  the 
building  by  a  code  (cipher)  lock  and  a  sepa- 
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Lessons  Learned  Checklist  Program  Observations 

□ 

Form  SSEB  organizational  structures  that  provide  the 
appropriate  additional  staff  to  manage  personnel, 
logistics,  and  operations. 

rate  key  lock  on  the  outer  entrance/exit 
door.  The  code  was  given  to  all  evaluators 
and  above;  factor  leads  and  the  SSEB 
management  had  keys  to  the  secondary 
lock.  During  normal  business  hours,  the 
secondary  lock  was  unlocked  to  allow 

SSEB  members  to  travel  freely.  This  en¬ 
sured  that  non-SSEB  personnel  did  not  gain 
access  to  the  building. 

□ 

Provide  facility/building  drawings  that  detail  the  re¬ 
quirements  of  each  room  in  terms  of  computers,  local 
area  network  drops,  phones,  tables,  chairs,  and  other 
furnishings.  Do  this  at  least  three  months  ahead  of 
time  so  that  any  necessary  work  can  be  completed 
on  time. 

□ 

Devise  a  physical  security  plan  to  ensure  that  only 
SSEB  personnel  have  access  to  the  SSEB  facility. 

□ 

Physically  relocate  the  SSEB  chairperson  to  the  PM 
office  prior  to  the  last  revision  (at  least  one  month 
prior  to  planned  approval)  of  the  source  selection 
plan.  This  will  provide  a  “sanity”  look  into  the  plan 
that  the  SSEB  inherits  from  the  PM  office.  This  will 
also  help  to  get  buy-in  from  the  SSEB  lead  since  he 
or  she  will  personally  be  involved  in  the  revision 
process. 

□ 

Ensure  that  the  SSEB  chairman  is  involved  with  any 
revisions  that  are  made  to  the  SSP. 

The  SSEB  chairman’s  one-month  involve¬ 
ment  with  revisions  of  the  source  selection 
plan  provided  a  positive  transition  from  the 
ARH  business  division  to  the  SSEB  man¬ 
agement  control. 

□ 

Ensure  that  the  installation  (AMCOM)  has  an  in- 
house  contract  for  managing  a  standardized  Micro¬ 
soft  Access  database  (government  owned)  for  use  by 
all  SSEBs  on  servers  in  all  special  studies  buildings. 

An  Army-owned  standardized  “user-friendly” 
database  is  required  to  store  SSEB  evalua¬ 
tion,  element,  sub-factor,  and  factor-level  roll¬ 
up  consensus  data. 

There  were  no  standardized  digi¬ 
tal/computer  SSEB  databases  offered  by 
the  government  for  use  in  facilities  to  prop¬ 
erly  store  the  data  from  evaluations.  The 
SSEB  management  team  coordinated  with 
SAIC  Inc.  to  view  the  “Auto-SSEB”  pro¬ 
gram,  which  has  been  the  only  database 
system  used  on  Redstone  Arsenal  by 

SSEBs.  The  Auto-SSEB  system  is  10  years 
old;  it  would  cost  about  $75,000  to  modify 
the  software  and  gain  two  weeks  of  contract 
support.  [The  program]  ultimately  tasked  a 
TSM-Recon/Attack  support  contractor  (an 
individual  with  immense  software  develop¬ 
ment  knowledge)  to  develop  and  maintain  a 
Microsoft  Access  database.  This  cost  the 
government  in  man-hours  just  a  fraction  of 
what  the  Auto-SSEB  software  would  have 
cost. 
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Lessons  Learned  Checklist 

Program  Observations 

□ 

Initiate  a  Memorandum  of  Agreement  (MOA)  for  all 
organizations  that  provide  personnel  to  the  SSEB. 

The  MOA  should  lock-in  the  personnel  so  they  are 
not  be  removed  from  the  board. 

Ensure  that  all  personnel  comprising  an 

SSEB  are  approved  in  writing  by  the  home 
organization  and  that  they  are  not  allowed 
to  be  removed  from  the  board.  Valuable 
time  is  lost  in  training  new  personnel  mid¬ 
stream  in  an  evaluation,  and  disruption  of 
the  SSEB  schedule  can  occur. 

The  acquisition  center  leadership  removed 
the  cost  factor  lead  two  months  into  the 
program  SSEB  and  provided  a  replacement 
factor  lead.  Because  of  this  disruption,  the 
most  probable  cost  had  to  be  completed  by 
an  advisor  to  the  SSEB;  the  cost  evaluation 
took  an  extra  three  days  to  complete  as  per 
the  SSEB  internal  schedule. 

□ 

Plan  for  an  intra-building  email  system  early  on  in  the 
planning  stage.  Procure  the  software  and  test  the 
database  system. 

An  intra-building  email  system  should  be 
attained  to  gain  efficiencies  for  SSEBs. 

Since  we  did  not  have  such  a  system,  valu¬ 
able  time  was  lost  because  SSEB  members 
had  to  physically  walk  from  one  room  to 
another  to  communicate.  Additionally,  the 
Directorate  of  Information  Management 
should  appoint  an  individual  who  is  trained 
to  set  up  and  maintain  the  email  system. 

□ 

Mandate  Early  Operational  Capability  (EOC)  re¬ 
sponse  processing  to  the  government  up  front  and  in 
writing  in  the  following  types  of  media:  email,  facsi¬ 
mile,  and  overnight  mailing  (no  exceptions). 

The  government  must  direct  offerors  to  util¬ 
ize  a  standard  communication  medium  to 
process  information  back  to  the  govern¬ 
ment.  Offeror-owned  websites  were  not 
reliable  for  time-sensitive  EOC. 

□ 

Ensure  the  entrance/exit  door  has  a  code  (cipher) 
lock  system  to  bolster  physical  security. 

To  ensure  that  the  area  is  free  of  non- 
authorized  personnel,  it  is  paramount  to  use 
a  cipher  lock  system  on  any  main  en¬ 
trance/exit  at  an  SSEB  facility. 

□ 

Schedule  the  SSP  at  the  mid-point  and  ensure  that  it 
is  compatible  with  the  general  officer/senior  execu¬ 
tive  service  schedules. 

It  was  difficult  to  schedule  the  source  selec¬ 
tion  plan,  mid-point  brief,  and  final  briefings 
for  the  SSA/SSAC  advisors  because  gen¬ 
eral  officer/senior  executive  service  sche¬ 
dules  conflicted  with  the  evaluation  timeline. 
Also  due  to  scheduling  conflicts,  the  mid¬ 
point  brief  was  “pushed  to  the  right’’  five 
days.  This  affected  the  contract  award  by 
the  same  number  of  days. 
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Lessons  Learned  Checklist  Program  Observations 

□ 

Develop  a  process  that  mandates  how  offerors’  res¬ 
ponses  to  the  EOC  will  be  transmitted  back  to  the 
government  for  processing. 

The  SSEB  did  not  mandate  to  the  offerors 
how  responses  to  EOC  would  be  transmit¬ 
ted  back  to  the  government  after 
processing.  Offerors  usually  provided  EOC 
responses  via  unclassified  email,  but  one 
offeror  requested  the  SSEB  to  utilize  their 
internal  website.  In  some  instances,  the 
website  had  internal  faults  and  the  contract 
specialist  experienced  delays  in  receiving 
timely  information.  This  slowed  the  review 
process  of  the  SSEB  management  team. 
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Appendix  A:  Longbow  Apache  Overview 


After  Action  Report  (AAR) 

Longbow  Apache  Block  III  Acquisition 
2004-2006 


Purpose 

Provide  lessons  learned  on  Apache  Block  III  (AB3)  program  actions  leading  up  to  Milestone  B 
DAB  approval  allowing  entry  into  the  System  Development  and  Demonstration  (SDD)  phase. 

Overview 

This  AAR  focuses  on  lessons  learned  over  a  two-year  period  with  emphasis  on  the  intensive  ef¬ 
forts  exerted  by  representatives  from  the  ASA(ALT)  Department  of  the  Army  System  Coordina¬ 
tor  (DASC)  in  SAAL-SAI;  G-3,  G-4,  G-6,  G-8,  Deputy  Assistant  Secretary  of  the  Army  for  Cost 
and  Economics  (DASA-CE),  ATEC,  Training  and  Doctrine  Command  (TRADOC)  System  Man¬ 
ager  (TSM) — Reconnaissance/ Attack  and  the  Apache  Attack  Helicopter  (AAH)  Project  Manag¬ 
er’s  Office  (AAH-PMO). 

As  the  requirements  and  materiel  solution  evolved,  it  then  brought  in  respective  subject  matter 
experts  from  the  various  OSD  offices  including  Acquisition  Technology  &  Logistics  (AT&L) 
Land  Warfare;  Comptroller;  Deputy  Director  for  Research  &  Engineering  (DDRE);  Program 
Analysis  &  Evaluation  (PAL  including  Cost  Analysis  Improvement  Group  (CAIG));  Director, 
Operational  Test  &  Evaluation  (DOTE);  Office  of  General  Counsel  (OGC);  Acquisition  Re¬ 
sources  &  Analysis  (ARA);  Logistics  &  Materiel  Readiness  (L&MR);  Science  &  Technology 
(S&T);  Defense  Policy  And  Procurement  (DPAP),  JCS  J-8,  and  National  Geospatial  Intelligence 
Agency  (NIMA). 

The  campaign  to  achieve  an  approved  Milestone  B  Decision  Review  on  28  June  2006  by  the  De¬ 
fense  Acquisition  Board  began  in  earnest  in  early  2004,  when  the  previous  AAH-PMO  planted  the 
initial  seeds  to  HQDA  leadership  via  a  series  of  briefings  informing  numerous  General  Officers  of 
the  need  for  a  technological  improved  AH-64D  Longbow  AB3  over  the  next  25  years.  Over  26 
tech  insertions  are  envisioned  for  the  AB3  to  improve  interoperability,  survivability  and  lethality 
over  the  current  Longbow  Apache  Block  II  configuration.  In  concert  with  justifying  a  material 
solution  to  the  Army  Secretariat  side  of  HQDA  was  the  need  for  an  AB3  requirements  definition 
by  the  TRADOC  community  (TSM  for  Recon/Attack  and  HQ  TRADOC  Combat  Developments 
and  Futures).  The  AB3  requirements  process  began  initially  as  an  Operational  Requirements  Doc¬ 
ument  (ORD)  in  early  2004  and  evolved  into  a  CDD  approved  by  both  the  Army  Requirements 
Oversight  Council  (AROC)  and  Joint  Capabilities  Board  (JCB)  using  the  recent  applicable  JCIDS 
process  culminating  with  a  JROCM  on  3  June  2006.  The  AB3  ORD  to  CDD  conversion  and  the 
associated  approval/validation  process  precipitated  numerous  FCB/JCB/JROC  briefings. 
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Appendix  B:  Armed  Reconnaissance  Heiicopter  Overview 


Extract  from  Milestone  B  After  Action  Report  for  the  Armed  Reconnaissance 
Helicopter  Program 
December  2005 


The  Process 

Despite  the  many  urban  myths,  the  fundamental  acquisition  process  works  fairly  well  overall.  It 
provides  a  good  cross  leveling  and  cross  checking  of  all  aspects  of  the  program  to  ensure  that  the 
correct  approach  is  being  used  to  support  the  war  fight.  That  is  not  to  say  that  additional  acquisi¬ 
tion  streamlining  is  not  necessary. 

There  are  three  embedded  activities  as  you  go  for  acceleration:  the  JCIDS,  acquisition,  and  con¬ 
tracting  pieces.  Each  activity  is  separate  and  unique  and  has  its  own  requirements.  PMs  must 
make  sure  that  they  have  a  primary  contact  leading  each  effort.  For  the  JCIDS  process,  it  is  the 
Training  and  Doctrine  Command  (TRADOC)  System  Manager  (TSM).  For  the  acquisition 
process,  it  is  the  PM.  For  the  contracting  process,  it  is  the  PM  plus  the  Aviation  and  Missile 
Command  (AMCOM)  Contracting  Office  support.  PMs  must  track  those  three  activities  in  paral¬ 
lel  and  make  sure  they  stay  in  lock  step.  However,  it  is  important  to  understand  that  all  parts  of  the 
process  move  at  different  speeds  and  not  all  parts  of  the  process  are  treated  with  equal  priority  and 
equal  effort.  Therefore,  you  have  to  balance  those  priorities  as  you  go  forward  in  terms  of  sche¬ 
duling  meetings;  consider  when  the  meetings  will  take  place  and  who  should  attend  them.  While 
it  is  important  to  understand  your  parochial  point  of  view  as  a  PM,  you  certainly  need  to  under¬ 
stand  the  other  priorities.  For  example,  as  you  go  through  the  process,  it  is  not  enough  to  under¬ 
stand  just  your  program;  you  have  to  understand  the  impact  of  your  program  with  other  Army  and 
OSD  programs. 

As  well  as  the  historical  execution  of  programs  within  the  Army  in  general,  programs  are  held 
accountable  to  both  the  good  and  bad  program  execution  of  the  past.  The  Army  may  give  up 
something  on  your  particular  program  in  order  to  support  a  strategic  decision  to  get  OSD  support 
across  many  areas.  In  our  program,  the  Army  consciously  did  not  fight  several  decisions  because 
there  were  three  other  new-start  programs  coming  through  the  same  process  and  they  did  not  want 
to  lose  the  ability  to  maintain  the  moral  high  ground  as  the  other  programs  came  through.  It  is 
important  that  you  realize  the  impact  of  what  you  are  giving  up  and  its  relationship  to  the  pro¬ 
gram. 

Moving  through  the  process,  is  critical  that  PMs  understand  that  there  are  no  shortcuts.  Every 
program  is  different,  but  the  fundamental  starting  place  for  all  programs  is  that  they  understand 
your  ACAT  level  and  what  the  law  says  you  must  do  and  what  your  Milestone  Decision  Authority 
(MDA)  will  accept.  The  items  that  are  required  by  law  are  very  hard  to  waive.  Some  programs 
may  indicate  that  they  — kipped”  steps  in  the  process,  but  in  most  cases,  you  will  find  that  they 
had  a  — ^de-back”  or  had  to  do  it  after  the  milestone  decision. 
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For  most  programs,  PMs  choose  and  embrace  the  process  of  getting  to  the  milestone  decision. 
Understand  early,  via  the  ASARC  secretary  and  through  the  OSD  DAB  secretary,  what  is  re¬ 
quired  and  what  the  MDA  expects.  You  can  then  focus  on  what  the  MDA  needs  by  working 
through  the  Integrating  Integrated  Product  Team  (IIPT)  process.  The  IIPT  process  is  not  going  to 
let  you  by-pass  what  needs  to  be  done.  So  rather  than  try  to  fight  that,  it  is  important  that  you  em¬ 
brace  it  and  put  the  assets  in  your  own  organization  in  place  to  do  that. 

Consistency 

As  you  go  through  the  process,  it  is  critical  to  make  sure  that  you  have  a  consistent  approach  in 
terms  of  briefings,  meeting  formats,  and  strategy.  Doing  this  saves  time  and  helps  you  to  avoid 
repeating  problems. 

Using  a  set  of  consistently  formatted  meetings  and  slides  is  beneficial  since  everyone  will  be  ac¬ 
customed  to  seeing  the  logistics  information,  programmatic  information,  milestones,  and  funding 
information  in  this  consistent  way.  Use  this  fundamental  set  of  slides  to  maximize  success  in  the 
process. 

We  used  the  Smart  Book  approach.  We  started  with  a  set  of  slides  that  we  consistently  used  as  the 
foundation  as  we  went  forward.  That  set  the  conditions  for  all  the  Army  IIPTs,  the  OSD  IIPTs, 
Overarching  Integrated  Product  Teams  (OIPT),  ASARCs,  and  DABs. 

Documentation 

It  is  important  to  understand  the  start-point  and  end-point  of  each  document  in  the  process.  We 
created  a  matrix  of  who  was  tasked  to  write  each  document,  who  was  assigned  to  review  each 
document  at  every  step,  where  each  document  stopped,  and  where  it  needed  to  continue.  Not  all 
Milestone  B  documents  are  OSD  documents,  some  stop  at  the  Army.  Understand  where  you  begin 
and  end  in  each  step  of  the  process  and  make  sure  your  people  have  that  information  as  you  go 
forward. 

The  organization  in  the  Milestone  B  preparation  period  needs  to  be  adaptive  and  proactive  in  the 
process.  In  so  doing,  a  smaller  office  provides  the  ability  to  do  several  key  tasks. 

First,  as  you  move  forward,  coordinate  the  37  Milestone  B  documents.  This  includes  the  business 
section,  the  technical  section,  the  logistical  section,  and  the  acquisition  section,  each  of  which  will 
move  at  a  different  speed. 

Next,  appoint  a  single  point  of  contact  in  the  office  to  track  the  milestone  documents.  Traditional¬ 
ly,  program  offices  have  hired  contractors  to  write  these  documents.  We  elected  not  to  do  that 
because  we  wanted  the  people  who  were  going  to  execute  the  program  to  write  the  documents. 
That  turned  out  to  be  a  valuable  asset  since  everyone  knew  one  another  and  understood  the 
processes;  additionally,  this  group  of  people  exercised  the  decision  process  during  the  SDD  period 
of  the  program. 
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This  last  piece  of  the  organization  is  in  support  of  the  Life  Cycle  Management  Center  (LCMC) 
concept.  Personnel  were  co-located  in  our  office  with  our  14  Table  of  Distribution  and  Allow¬ 
ances  (TDA)  positions  and  2  additional  military  positions  for  a  total  of  16  TDA  positions.  Com¬ 
bined  with  key  players  in  the  community,  representatives  from  the  following  organizations 
teamed  with  the  TSM  to  write  the  documents. 

•  Army  Test  and  Evaluation  Command  (ATEC) 

•  Aviation  Engineering  Directorate  (AED) 

•  Integrated  Material  Management  Center  (IMMC) 

•  Safety  Center,  Configuration  Control,  Software 
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Appendix  C:  UH-60M  Black  Hawk  Executive  Summary 


UH-60M  BLACK  HAWK  Modernization  Program 
Miiestone  C 

After  Action  Report 


Executive  Summary 

The  UH-60M  Modernization  Program  conducted  its  Milestone  C  preparation  during  the  winter  of 
2004-2005.  This  effort  culminated  in  a  Defense  Acquisition  Board  (DAB)  briefing  on  15  March 
2005  and  a  signed  Acquisition  Strategy  and  Acquisition  Decision  Memorandum  on  3 1  March 
2005. 

During  the  course  of  these  events,  we  attempted  to  follow  the  processes  that  are  outlined  in  the 
DoD  5000  series,  the  Defense  Acquisition  Guidebook,  and  Army,  OSD,  and  Joint  Staff  guidance 
documents. 

We  found  that  in  many  cases  the  documented  processes  and  procedures  are  not  always  understood 
by  the  staffs,  may  not  be  followed,  and  sometimes,  do  not  meet  the  requirements  of  real-life  situa¬ 
tions. 

Among  the  greatest  issues  we  encountered  was  how  to  deal  with  the  UH-60M  Upgrade  program, 
lack  of  communication  between  the  decision  makers  and  staffers  and  subsequently  the  PM,  and 
interaction  between  staffers  and  their  principals. 

The  PMO  tried  to  keep  the  UH-60M  Upgrade  program  from  influencing  the  UH-60M  Milestone 
decision.  The  PM,  very  early  in  the  game  said  they  would  be  willing  to  treat  it  as  a  separate  pro¬ 
gram.  However,  the  OSD  staff  wanted  to  tie  the  two  programs  together  and  the  Office  of  fhe  Gen¬ 
eral  Counsel  (OGC),  the  Comptroller,  and  AT&L  Policy  could  not  figure  out  how  to  execute  the 
Upgrade  program  in  light  of  what  the  5000  series  program  advocated.  Throughout  these 
processes,  the  PM  spent  more  time  and  effort  on  the  Upgrade  program  than  it  did  on  the  baseline 
production  decision. 

Compounding  this  problem  was  a  lack  of  decision  authority  guidance.  In  November,  OSD  AT&L 
Systems  and  Policy,  OGC,  and  Comptroller  directed  a  course  of  action  for  Milestone  C  including 
how  to  handle  the  Upgrade  program.  Two  days  prior  to  the  OfPT,  the  director  of  Defense  Sys¬ 
tems,  was  pre-briefed  by  his  staff  and  said  he  would  not  buy  into  the  proposed  strategy.  Thus, 
three  months  of  effort  was  altered  because  the  staff  had  not  communicated  to  their  boss  and  re¬ 
ceived  his  intent. 

The  PM  also  found  that  the  staff  principals  were  not  well  informed  about  the  program  and  addi¬ 
tional  one-on-one  briefings  were  required.  These  briefings,  in  the  author’s  opinion,  were  instru¬ 
mental  in  resolving  issues  that  languished  at  the  staff  level.  While  the  AAE  and  DAE  may  not 
think  such  briefings  are  unnecessary,  we  found  they  are  absolutely  essential. 
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This  after  action  report  provides  input  about  how  the  UH-60M  Modernization  Product  Office  ac¬ 
complished  the  milestone  decision  process.  It  includes  a  resume  on  the  actions  taken  to  develop, 
staff,  and  obtain  approval  for  each  document.  It  contains  the  documents,  the  decision  briefings 
and  the  IIIPT  briefings.  It  furnishes  issues  we  encountered  and  provides  recommendations  regard¬ 
ing  the  actual  process  to  follow. 

The  opinions  contained  are  those  of  the  people  who  accomplished  the  effort  and  do  not  necessari¬ 
ly  reflect  those  of  the  Department  of  the  Army  or  the  Department  of  Defense. 


Robert  H.  Lunn 

Lieutenant  Colonel,  U.S.  Army 

Product  Manager,  UH-60M 
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Appendix  D:  Raven  Unmanned  Aerial  System  AT&L  Article: 
“Acquisition  in  the  Fast  Lane — The  Small 
Unmanned  Aerial  Vehicle  (SUAV)  Product  Office” 

By  William  R.  (Bobby)  Ellis,  Jr. 

Note  from  the  authors:  We  include  this  article  here  since  it  accurately 
represents  the  experiences  of  a  typical  product  manager,  and  best 
characterizes  rapid  acquisition  and  rapid  fielding  choices.^ 


The  Raven  (RQ-1  IB)  Small  Unmanned  Aerial  Vehicle  (SUAV)  offers  a  compelling  story  of  rapid 
response  to  urgent  theater  needs.  The  SUAV  Product  Office  (PO)  moved  from  an  initial  capabili¬ 
ty,  demonstrated  through  a  Rapid  Fielding  Initiative,  to  Full  Rate  Production  (FRP)  in  less  than 
fifteen  months.  Included  in  that  short  time  span  were  full  and  open  competition  for  source  selec¬ 
tion,  Milestone  C-Low  Rate  Initial  Production  (TRIP)  decision.  Initial  Operational  Test  and  Eval¬ 
uation  (lOT&E),  and  finally  an  FRP  decision.  The  culminating  event  was  First  Unit  Equipped  in 
fifteen  months!  Although  accomplished  in  a  relatively  short  time  span  for  an  acquisition  Program 
of  Record,  there  were  numerous  obstacles  that  had  to  be  overcome  to  achieve  this  aggressive 
schedule. 

Obstacles 

The  SUAV  was  widely  accepted  as  essential  to  the  commander’s  needs  in  the  Global  War  on  Ter¬ 
rorism,  which  provided  the  impetus  for  rapid  acquisition.  Over  the  course  of  the  fifteen  months, 
the  SUAV  team  achieved  important  objectives.  The  team  also  overcame  major  obstacles  such  as: 

•  stood  up  the  SUAV  PO 

•  supported  development  and  staffing  requirements 

•  completed  source  selection 

•  established  program  elements  (PE)  for  Research  Development  Test  and  Evaluation  (RDT&E) 
Funding  and  Operational  Maintenance  Account  (OMA)  funding 

•  planned  and  executed  an  lOT&E,  including  replacing  the  scheduled  test  unit  with  less  than  60 
days  before  test  start  date 

•  lost  50%  of  FY 07  funding  and  25%  of  FYl 0  funding 

The  SUAV  PO  simultaneously  supported  the  SUAV  Rapid  Equipping  Force  Initiative  systems  in 
Operation  Iraqi  Freedom  (OIF)  and  Operation  Enduring  Freedom  (OEF);  integrated  requirements 
from  Special  Operations  Command  (SOCOM)  and  the  Marine  Corps;  and  became  a  program  of 
Joint  Interest  and  Funding. 


Reprinted  with  permission  from  Army  AL&T.  The  article  originally  appeared  in  the  July-September  2007  issue  of 
Army  AL&  T  Magazine 

(http://asc.army. mil/altmag/default_previous.cfm?issueYear=2007&issueMonth=3_JulAugSept). 
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The  Right  People 

In  June  2005,  the  Unmanned  Aircraft  Systems  (UAS)  Project  Manager  decided  to  break  the 
SUAV  Program  of  Record  out  of  the  Ground  Maneuver  PO  and  create  a  separate  SUAV  PO. 
Three  personnel  from  Ground  Maneuver  transferred  to  SUAV.  A  non-board-selected  Product 
Manager  (PM)  and  a  deputy  were  hired  to  execute  the  program  and  constitute  the  office.  Their 
first  act  was  to  assemble  the  necessary  personnel  to  staff  the  new  PO.  Experience  and  maturity 
were  key  qualifiers  for  individual  team  members.  A  hybrid  organization  was  created  and  staffed 
with  personnel  from  within  the  Aviation  and  Missile  Command  (AMCOM).  The  organization 
consisted  of  the  PM  and  deputy,  a  small  core  of  matrix  personnel  from  the  AMCOM  functional 
elements,  business  management  from  the  parent  UAS  Project  Office,  and  supporting  contractor 
personnel.  The  goal  was  to  keep  the  organization  as  small  as  possible  while  allowing  all  the  func¬ 
tional  areas  to  be  covered  (e.g.,  program  management,  engineering,  logistics,  and  business).  Eight 
months  into  the  execution  of  the  program,  the  staff  numbered  thirty  personnel.  The  team  members 
shared  several  key  traits:  a  driven  desire  and  focus  on  supporting  the  soldier,  an  ability  to  multi¬ 
task,  a  mature  demeanor,  ten  plus  years  experience  in  their  functional  areas,  and  a  willingness  to 
work  long  hours  and  travel.  The  SUAV  PMO  paid  a  premium  price  to  capture  its  staff;  however, 
by  focusing  on  the  higher  percentile  personnel,  the  PMO  was  able  to  perform  as  a  program  office 
from  the  onset.  Everyone  in  the  PO  was  expected  to  work  outside  his  or  her  normal  functional 
areas  to  support  the  entire  team. 

Source  Selection 

The  Source  Selection  Board  for  the  SUAV  began  on  5  June  2005.  Seven  vendors  provided  pro¬ 
posals  for  evaluation.  Source  selection  consisted  of  the  following  six  phases. 

1 .  solicitation  and  receipt  of  proposals 

2.  questions  and  answers 

3.  paper  down-selection  to  two  vendors 

4.  fly-off  of  the  two  competitors 

5.  best  and  final  proposal 

6.  vendor  selection 

An  immediate  issue  arose  as  most  competitors  were  small  businesses  and  needed  additional  time 
to  develop  proposals.  After  the  down-select  to  two  contractors.  Hurricane  Katrina  hit  the  Gulf 
coast.  One  vendor  requested  and  received  a  delay  in  accomplishing  the  fly-off  because  of  their 
participation  in  the  relief  assistance  to  New  Orleans.  This  situation,  combined  with  delays  in 
source  selection,  slipped  Milestone  C  and  contract  award  for  TRIP  by  two  months,  to  October 
2005.  Funding  for  the  TRIP  systems  was  thus  jeopardized,  having  originated  from  FY04  Com¬ 
anche  RDT&E  and  would  expire  at  the  end  of  September  2005.  To  prevent  further  schedule  slip¬ 
page,  PM  UAS  internally  reprogrammed  funding  from  SUAV  to  other  UAS  programs.  The 
SUAV  program  received  replacement  RDT&E  funding  from  reprogramming  of  FY05  and  FY06 
UAS  programs.  Most  importantly,  while  the  SUAV  overall  program  slipped,  the  lOT&E  sche¬ 
duled  for  June  2006  did  not. 
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Programmatics 

The  SUAV  program  was  established  with  a  single  PE  budget  line  for  procurement.  The  PM 
SUAV  took  action  to  establish  PEs  for  both  RDT&E  and  OMA.  This  required  close  cooperation 
with  Army  G8  and  the  Army  Budget  Office  (ABO).  The  Army  established  the  necessary  budget 
lines  for  FY08  and  beyond.  This  action  was  time  consuming  with  repeated  trips  to  Washington, 
D.C.  to  brief  the  G8  and  ABO  personnel.  The  time  spent  with  these  offices  secured  champions  for 
the  SUAV  program  during  Program  Objective  Memorandum  (POM)  development  activity.  The 
key  to  a  positive  outcome  for  the  SUAV  PMO  was  daily  contact  with  key  personnel  and  offices 
within  the  Pentagon. 

Test  and  Evaluation 

Originally,  the  SUAV  lOT&E  was  scheduled  for  June  2006.  In  late  November  2005,  the  designat¬ 
ed  test  unit  was  alerted  that  they  would  deploy  early  and  not  be  available  for  lOT&E.  This  was  a 
devastating  blow  to  the  SUAV  program.  Due  to  the  Global  War  on  Terrorism  (GWOT)  and  unit 
rotations,  no  replacement  unit  would  be  unavailable  until  March  2007,  at  the  earliest.  This  caused 
Army  G8  and  G3  to  redirect  SUAV  funding  to  cover  other  Army  requirements  by  decrementing 
the  FY07  SUAV  Budget  by  50%  and  the  FYIO  SUAV  budget  by  25%.  To  maintain  program 
schedule  for  production  and  fielding,  the  SUAV  PM  began  directly  contacting  units  to  provide  the 
necessary  forces  to  accomplish  the  lOT&E.  The  following  three  possible  courses  of  action  arose. 

•  Units  from  the  2““*  Infantry  Division  (ID)  in  Korea  agreed  to  support  lOT&E.  The  logistical 
considerations  to  make  this  happen,  although  staggering,  were  not  impossible  to  meet.  Addi¬ 
tional  funding  over  the  original  planned  cost  for  the  lOT&E  was  required.  A  critical  hurdle 
appeared  when  the  Korean  frequency  manager  disapproved  the  downlink  frequency,  which 
would  require  a  costly  hardware  reconfiguration.  Flowever,  the  Army  Test  and  Evaluation 
Command  (ATEC)  objected  since  the  new  configuration  would  not  be  production  representa¬ 
tive.  Another  possibility  was  to  move  the  test  unit  to  a  location  where  SUAV  frequencies 
were  approved  for  use.  All  of  the  objections  for  the  2”‘*  ID  were  surmountable  but  were  not 
the  best  solution  due  to  additional  funding  and  the  logistical  implications. 

•  The  United  States  Marine  Corps  (USMC)  was  considered  as  a  potential  test  unit;  however, 
their  Tactics,  Techniques,  and  Procedures  (TTPs)  were  not  the  same  as  Army  Infantry.  The 
PM  decided  to  continue  to  pursue  this  course  of  action  while  giving  the  Army  one  last  chance 
to  provide  the  unit  for  lOT&E. 

•  The  PO  contacted  Army  units  that  had  used  the  previous  version  of  SUAV,  Raven-A,  in  the 
GWOT.  As  the  Raven-B  had  won  the  competition  for  the  SUAV,  these  units  were  generally 
familiar  with  the  capabilities  of  the  system.  One  unit,  the  U*  Cavalry  Division  (CAV)  in  Ft 
Flood,  Texas,  was  very  receptive  to  supporting  lOT&E  if  the  unit  under  test  would  become 
the  first  equipped.  All  parties,  including  the  test  community,  eventually  agreed  to  this  course 
of  action. 

The  4*  Brigade  Combat  Team  (BCT),  U‘  CAV,  Fort  Bliss,  Texas  would  support  the  lOT&E  test 
using  the  combined  facilities  of  Fort  Bliss  and  White  Sands  Missile  Range.  This  allowed  the  pro¬ 
gram  schedule  to  remain  unchanged  for  lOT&E  in  June  2006.  The  commander,  staff,  and  soldiers 
of  the  4*  BCT  gave  a  collective  herculean  effort  to  ensure  success.  They  accomplished  the  task 
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concurrent  with  new  unit  staffing,  equipping,  training  and  preparation  for  a  rotation  to  the  Nation¬ 
al  Training  Center  and  deployment  to  theater  within  two  months  of  the  scheduled  end  of  lOT&E. 
In  many  ways  they  were  the  critical  — ndiin  the  horseshoe”  leading  to  the  eventual  fielding  on 
Raven-B  to  the  Army. 

Success 

There  were  many  challenges  for  the  SUAV  program  to  overcome.  Success  required  that  the  office 
address  all  the  obstacles  of  the  acquisition  process,  funding,  and  test  and  evaluation.  The  follow¬ 
ing  tenets  helped  the  PMO  achieve  success. 

•  Select  the  right  people  (i.e.,  the  most  valuable  resources). 

•  Never  give  up. 

•  Think  outside  of  the  box. 

•  Remember  that  “no”  is  not  the  final  answer  (i.e.,  remember  to  rethink  the  question). 

•  Solicit  senior  leaders  to  become  champions  of  the  program  (i.e.,  conduct  information  flow). 

•  Work  with  and  help  organizations  understand  the  validity  of  your  system  (e.g.,  ABO,  G8,  G3, 
etc.). 

•  Make  reasonable  demands  (i.e.,  don’t  ask  for  the  moon). 

•  Link  the  program  to  other  services  (e.g.,  powerful  stakeholders). 

•  Use  this  rule:  — flit  is  in  someone  else’s  lane  and  they  can’t  do  it. .  .do  it  yourself!” 

These  tenants  are  not  new;  however,  by  being  aggressive  in  their  application,  the  SUAV  program 
was  able  to  overcome  its  challenges.  A  successful  lOT&E  maintained  the  original  timeline  and 
resulted  in  a  positive  report  from  both  ATEC  and  the  Director,  Operational  Test  and  Evaluation. 
This  led  to  plus-ups  in  the  budget  for  the  SUAV  program.  Fortunately,  all  lost  funds  were  recov¬ 
ered  in  the  POM-build  process. 

In  short,  the  SUAV  PMO  has  been  able  to  react  to  early  demands  for  fielding  and  training  of  units 
for  the  Raven-B  SUAV.  SOCOM  and  the  Marine  Corps  were  fielded  Raven-B  ahead  of  schedule. 
UAS  requirements  from  commanders  in  the  field  are  growing  exponentially  and  the  PO  continues 
to  exceed  the  demands  placed  on  it  for  SUAV  systems  by  meeting  the  soldier’s  needs. 

About  the  Author 
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Appendix  E:  Acronyms 


AAE 

Army  Acquisition  Executive 

AAH 

Apache  Attack  Helicopter 

AAR 

After  Action  Review 

AB3 

Apache  Block  III 

ABO 

Army  Budget  Office 

ACAT 

Acquisition  Category 

ACP 

Army  Cost  Position 

ADM 

Acquisition  Decision  Memorandum 

AED 

Aviation  Engineering  Directorate 

AMCOM 

Aviation  and  Missile  Command 

AoA 

Analysis  of  Alternatives 

APB 

Acquisition  Program  Baseline 

AR 

Army  Regulation 

ARA 

Acquisition  Resources  &  Analysis 

ARM 

Armed  Reconnaissance  Helicopter 
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AROC 

Army  Requirements  Oversight  Council 

ASA{ALT) 

Assistant  Secretary  of  the  Army  (Acquisition,  Logistics,  and  Technology) 

ASARC 

Army  Systems  Acquisition  Review  Council 

ASEO 

Army  Systems  Engineering  Office 

ASR 

Acquisition  Strategy  Report 

AT&L 

Acquisition  Technology  &  Logistics 

ATEC 

Army  Test  and  Evaluation  Command 

BCT 

Brigade  Combat  Team 

BOIP 

Basis  of  Issue  Plan 

C4I 

Command,  Control,  Computing,  Communication,  and  Intelligence 

CAIG 

Cost  Analysis  Improvement  Group 

CARD 

Cost  Analysis  Requirements  Document 

CAV 

Cavalry  Division 

CCA 

Component  Cost  Analysis 

CDD 

Capability  Development  Document 

CJCSI 

Joint  Chiefs  of  Staff  Instraction 
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COIC 

Critical  Operational  Issues  and  Criteria 

CRB 

Cost  Review  Board 

DA 

Department  of  the  Army 

DAB 

Defense  Acquisition  Board 

DAE 

Defense  Acquisition  Executive 

DASA-CE 

Deputy  Assistant  Secretary  of  the  Army  for  Cost  and  Economics 

DASC 

Department  of  the  Army  Staff  Coordinator 

DDRE 

Deputy  Director  for  Research  &  Engineering 

DoD 

Department  of  Defense 

DOT&E 

Director,  Operational  Test  and  Evaluation 

DPAP 

Defense  Policy  And  Procurement 

DT 

Developmental  Test 

DUSA-OR 

Deputy  Under  Secretary  of  the  Army  for  Operations  Research 

EOC 

Early  Operational  Capability 

FRP 

Full-Rate  Production 

GWOT 

Global  War  on  Terrorism 
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HQDA 

Headquarters,  Department  of  the  Army 

ICE 

Independent  Cost  Estimate 

ID 

Infantry  Division 

MPT 

Integrating  Integrated  Product  Team 

IMMC 

Integrated  Material  Management  Center 

lOT&E 

Initial  Operational  Test  and  Evaluation 

IPT 

Integrated  Product  Team 

ISP 

Information  Support  Plan 

ITAB 

Information  Technology  Acquisition  Board 

JCB 

Joint  Chiefs  of  Staff  Functional  Capabilities  Board 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

JROC 

Joint  Requirements  Oversight  Council 

JROCM 

Joint  Requirements  Oversight  Council  memorandum 

JTA 

Joint  Technical  Architecture 

JTRS 

Joint  Tactical  Radio  System 

KPP 

Key  Performance  Parameter 
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LCMC 

Life  Cycle  Management  Center 

LFT&E 

Live  Fire  Test  and  Evaluation 

LM&R 

Logistics  and  Materiel  Readiness 

LRIP 

Low  Rate  Initial  Production 

M&S 

Modeling  and  Simulation 

MDA 

Milestone  Decision  Authority 

MEP 

Mission  Equipment  Package 

MER 

Manpower  Estimate  Report 

MILDEP 

Military  Department 

MOA 

Memorandum  of  Agreement 

NIMA 

National  Geospatial  Intelligence  Agency 

O&S 

Operation  and  Support 

OEF 

Operation  Enduring  Freedom 

OGC 

Office  of  General  Counsel 

OIF 

Operation  Iraqi  Freedom 

OIPT 

Overarching  Integrated  Product  Team 


CMU/SEI-2010-TR-006  |  41 


OMA 

Operational  Maintenance  Account 

ORD 

Operational  Requirements  Document 

OSD 

Office  of  the  Secretary  of  Defense 

OT 

Operational  Test 

PAE 

Program  Analysis  and  Evaluation 

PBL 

Performance-Based  Logistics 

PE 

Program  Element 

PEO 

Program  Executive  Office 

PM 

Product  Manager 

PMO 

Program  Management  Office 

PO 

Product  Office 

POC 

Point  of  Contact 

POE 

Program  Office  Estimate 

POM 

program  objective  memorandum 

RDT&E 

Research  Development  Test  and  Evaluation 

RFP 

Request  for  Technology 
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S&T 

Science  &  Technology 

SAAL 

Secretary,  Acquisition  and  Systems  Management 

SDD 

System  Development  Demonstration 

SEP 

System  Engineering  Plan 

SER 

System  Evaluation  Report 

SETA 

Systems  Engineering  and  Technical  Assistance 

SOCOM 

Special  Operations  Command 

SSA 

Source  Selection  Authority 

SSAC 

Source  Selection  Advisory  Council 

SSEB 

Source  Selection  Evaluation  Board 

STRAP 

System  Training  Plan 

SUAV 

Small  Unmanned  Aerial  Vehicle 

T&E 

Test  and  Evaluation 

TDA 

Table  of  Distribution  and  Allowances 

TEMP 

Test  and  Evaluation  Master  Plan 

TRA 

Technology  Readiness  Assessment 
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TRADOC 

Training  and  Doctrine  Command 

TSM 

TRADOC  System  Manager 

TTP 

Tactics,  Techniques,  and  Procedures 

UAS 

Unmanned  Aircraft  System 

USAAVNC 

United  States  Army  Aviation  Center 

USMC 

United  States  Marine  Corps 

WIPT 

Working  Integrated  Product  Team 

WSTAWG 

Weapons  Systems  Technical  Architecture  Working  Group 
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